Previous Page TOC Next Page



- 9 -
A Tale of Three File Systems


I came up with the rather whimsical title for this chapter after contemplating the various possibilities for file system use under Windows NT. When you look at Windows NT, you're seeing an operating system that can use more file system formats than any other operating system to date. Think about it; you have a choice of three base operating systems: FAT (file allocation table)/pseudo-VFAT (virtual file allocation table), NTFS (new technology file system or Windows NT file system), and HPFS (high performance file system). You also need to remember that Windows NT is designed to work on more than one hardware platform. As a user, you won't see any additional capabilities in the file system because of the multiplatform nature of Windows NT, but the file system does need extra flexibility to make this all work.

I want to mention a little more about my pseudo-VFAT entry in the previous paragraph. You'll find it interesting to see that Windows NT supports long file names as easily on a FAT-formatted drive as it does with any other drive. If Windows NT merely provided a true FAT file system, you couldn't use long file names. I also found it interesting that these long file names are as accessible from the DOS prompt as they are from Explorer. You'll also find that Windows NT uses many of the same DLLs Windows 95 does (well, not precisely the same) to provide FAT file system access. Microsoft's documentation won't even mention VFAT, but I feel that calling the level of Windows NT FAT file system support VFAT is more accurate. I'll get into the details of VFAT later in the chapter when I talk about the Windows NT architecture.

The purpose of this chapter is to tell you about the various file systems Windows NT supports. I'll describe the architecture first and then the individual differences between the various file systems. I think it's important to understand how Windows NT views the file system before you attempt to make changes to it. Once I fully discuss the theory, I'll examine some user-related issues such as viewing files and some of the new Windows NT additions such as LNK files. I'll also spend some time looking at the utility end of file system support. I'll discuss various methods you can use to protect your file system from data loss or corruption, for example, such as redundant array of inexpensive disks (RAID) and disk mirroring.

An Overview of the Windows NT File System


Take a tour of the Windows NT file system. Before you can begin to understand the file system support provided by Windows NT, you need to understand why there are so many of them. My hard drives have a proliferation of file systems. Right now, I can boot Windows for Workgroups 3.11, Windows 95, Windows NT, and OS/2. All four of these operating systems support the FAT file system. The last three also use their own file systems. Of the three, only the VFAT file system used by Windows 95 looks familiar to those of us who grew up using DOS. HPFS and NTFS are enhanced file systems that Microsoft created from scratch because no one thought the FAT file system could ever be repaired. (I'll look at a few of the remaining problems with VFAT in the following paragraphs.)

Microsoft designed all of these file systems at one time or another to obtain various goals. The FAT file system, for example, is actually based on UNIX. Microsoft had to have a file system when they built DOS—the FAT file system is the result. Unfortunately, Microsoft's first attempt wasn't as good as it could have been. They used a 12-bit allocation scheme that looked huge when DOS was young but soon caused problems when the size of a hard disk exceeded the 32MB boundary. The next version of FAT used 16-bit table entries—allowing the user to create much larger partitions. In reality, there are two different FAT schemes (12-bit and 16-bit), but from a user's perspective, there's only one.

When OS/2 came along, Microsoft decided they needed something a bit faster than FAT—HPFS. One of the problems with FAT on a large hard drive is that the drive information is located at one end of the drive. The location of the information forces the drive to work harder and reduces overall performance. In addition, the linear list format FAT uses to store the directory isn't the most efficient way to find information. HPFS uses a B-Tree directory structure that speeds access by a great amount. A B-Tree is a special software structure used by programmers for things such as database managers and files where you need to search for something and find it quickly. I could dazzle you with a lot of statistics about just how fast a B-Tree is, but instead just concentrate on the fact that it's faster. HPFS also provides enhanced reliability and other features I'll describe later in the chapter.

Windows NT provided yet another opportunity for Microsoft to fiddle with the file system. NTFS is an improvement from a number of technical perspectives that I'll describe later in this section. The two features that differentiate NTFS from HPFS are the capability to use larger files and partitions and the fact that NTFS is more fault tolerant. Anyone who has waited more than an hour for OS/2 to complete a CHKDSK command knows exactly what I mean. HPFS doesn't handle power failures very well at all. The bottom line for you as a user is that Microsoft stressed reliability when it created NTFS.

Finally, Windows 95 came along. Users wanted the capability to use long file names, but Microsoft needed a method for easily updating these systems, and that meant keeping the FAT file system. The compromise is the VFAT file system. VFAT doesn't require the resources that NTFS does, but it enables the user to use long file names. If you take a good look at Windows NT, you see that a good deal of the Windows 95 VFAT technology comes from the way that Windows NT handles the FAT file system.

What do you do with a system that's literally bogged down with incompatible file systems? You could take the easy way out—the way I originally took when I started working with OS/2. If you stick with the FAT file system, you'll certainly get all the operating systems talking to each other and run into a minimum of problems.

This solution has only one problem: If you stick with the FAT file system, you'll have compatibility, but you'll also miss out on the special features each of the other file systems has to offer. Both NTFS (Windows NT file system) and HPFS (high-performance file system) offer improved reliability and a higher access speed than the old FAT file system. The battle's still raging over which one is better—HPFS or NTFS. My personal favorite is NTFS, but that's another story.



Peter's Principle: A Method of Dealing with Multiple File Systems

After a lot of thought, I finally came up with a middle-ground solution to the problem of dealing with multiple file systems on one computer. It offers the maximum in compatibility yet lets me make the most out of what the other file systems have to offer.

The first thing I did was partition my drives. I set aside one partition for each of the operating systems installed on my machine. I had to do that anyway to get everything to boot correctly. Each operating system's specific partition uses the special file format it provides. This way, the operating system and its utility programs can benefit from the improved performance and reliability the new file system offers. I also stuck any operating system-specific applications in these partitions.

Once I figured out where each operating system would go, I installed them. Each installation required a bit of time and patience, but I got through it. It's important to test the capability to boot each operating system after you install a new one. Both Windows NT and Windows 95 like to overwrite the bootable partition marker. This means whatever boot manager you have installed won't boot until you use a disk editor to set the active partition back to its original position.

After I installed the operating systems and tested the boot sequence, I had one large partition left (actually I set the whole second drive aside). I labeled the partition on this drive COMMON and placed all my data and common applications there. It uses the FAT file system so everyone can access it. In some cases, I had to install each application once for each operating system. If you're careful, though, you can determine which files to copy from your Windows SYSTEM directory into each of the other SYSTEM directories. (DLLs and VxDs need to appear in the SYSTEM directory in most cases, or Windows won't be able to find them.) Is this a perfect solution? Not by a long shot. It's a solution that works, though.

Why did I go through this entire rundown on my system configuration? I think you might find yourself in the same dilemma I had. You have to test out all (or at least many) of the solutions available today, which means keeping multiple operating systems on your machine. This solution might be just what the doctor ordered when it comes time to test an OS/2 or Windows NT solution that the entire company might adopt. If you don't test the advanced file system that comes with the operating system, can you really say you tested everything when the time comes to make a decision?


Now that you have a better idea of what the issues are, look at the file system architecture. Windows NT has a lot to juggle when it comes to file system access. Figure 9.1 shows you how it gets the job done. The following list provides an overview of each of the architectural elements.

Figure 9.1. The Windows NT file system architecture has a lot to handle.



Tip: You'll notice that I've placed a special type of box around the HPFS file system driver. The reason is simple: The new version of Windows NT doesn't ship with a HPFS driver (at least not at the time of this writing). You can get around this problem, though, because the HPFS driver from the 3.5x version of Windows NT works just fine with the 4.0 version. All you need to do is install the new version of Windows NT on top of the old one. Of course, you must install HPFS support in the previous version first.


The FAT/VFAT File System


Now that I have some preliminaries out of the way, take a look at the VFAT file system provided with Windows NT. I use the term VFAT because of the kind of support that Windows NT provides; it is a lot more like the support provided by Windows 95 than the original form of FAT file system you used in DOS. As I said in an earlier chapter, one of the reasons for Windows 3.0's success was that the user could upgrade DOS to use it. In other words, the user could make the transition slowly without giving up a comfortable environment. Windows NT continues this line of reasoning, even maintaining a level of compatibility with the old FAT file system. (Unlike Windows 95 though, you can always choose the higher performance of the other file systems provided with Windows NT.)



Note: Windows NT Version 3.1 and below don't support long file names on FAT file partitions. This feature became available in Version 3.5. Microsoft added it specifically to work with Windows 95.

Why do we need yet another form of FAT file system when it's already out of date? People weren't satisfied with the old 8.3 file names. They wanted long file names, and the FAT file system can't provide this feature. On the other hand, trying to move some people from the FAT file system they're comfortable with to NTFS has proven less than popular. The VFAT file system represents an effort on the part of Microsoft to give people what they want and still maintain a level of compatibility with previous versions of DOS (and more important, the applications that ran under it).

Microsoft had another reason for adding VFAT support to Windows NT. You can't use NTFS on a floppy drive (or some types of floptical drives). The only file system that works on this media is FAT. Adding long file name support to FAT (making it VFAT) enables a user to move a file from one place to another without losing the long file name. Sure, it's a small consideration, but it's an important one as far as I'm concerned. I don't use floppy disks very much anymore—I can't even remember the last time I actually bought a new one. When I do use a floppy disk, though, it's usually to move data from my workstation to a notebook. Imagine how much of a hassle it would be to change the file names of the files I moved simply because my floppy drive didn't support the long file names provided by the operating system. For this reason alone, I think VFAT will be around for the foreseeable future—at least until Microsoft finds a way to move NTFS to floppy disks.

The following sections provide you with a bit of history and then a current look at the way Windows handles file access (at least for the FAT file system). It's important to start at the beginning to see what you have gained with various versions of Windows. Even more important, this historical view will help you understand certain constraints Microsoft programmers faced when they designed the VFAT file system used by Windows NT. It's easy to start out with a new product and design in all the features people want today. It's another story altogether to start with something that was fine yesterday and redesign it to meet today's needs. Windows NT isn't a completely new operating system; it still has to provide some compatibility with the older file systems used by previous versions of Windows. Fortunately, you aren't shackled to those old file systems; you can move on to the next stage in computer development if you really want to. I've already covered some of this reasoning earlier in the chapter, so I won't discuss it again here. VFAT is probably the last stop for the venerable DOS file system.

A Look at Windows Under DOS


Everyone who's worked with DOS and Windows 3.x knows that they have at least one thing in common: the FAT file system. That relationship between DOS and Windows 3.x also causes some problems for the user. Consider the speed issue many people bring up when you talk about using Windows. Because this older version of Windows rides on top of DOS, it must use some DOS services to access the hardware. The hard disk drive falls into this category. DOS provides all the file services Windows 3.x uses. In fact, this is about the only DOS service Windows 3.1 does use.

What using DOS to provide file services means to the user is that the system has to slow down every time Windows wants to access the hard drive. To see what I mean, look at Figure 9.2. Every time Windows wants to access the hard drive, it has to create a request in a format DOS will understand, switch over to real mode so that it can access DOS, and then wait for DOS to get the job done. Meanwhile, all those applications that are supposed to do something in the background get suspended. Remember, the Intel processor can't multitask in real mode; it can do that only in protected mode. Once DOS finds the bit of information Windows needs, Windows has to copy that information out of the conventional memory space into an area it can reach in protected mode. It must then switch the processor from real mode back into protected mode.

Figure 9.2. Windows 3.1 needs to switch from protected mode to real mode to access the hard drive through DOS.

The transition from real mode to protected mode is only an inconvenience—it wastes time your machine could use to process information. There are more insidious problems with using real mode drivers. Every time Windows has to make the switch from protected mode to real mode, it becomes vulnerable to attack from a maverick application. When the processor is in real mode, the operating system can no longer track system activity. The processor won't alert the operating system when an application creates a memory fault. As a result, an application could crash the system before Windows 3.x even knows what is going on.

32-Bit Access Under Windows 3.1


Windows 3.1 provided a new feature called 32-bit access. This feature reduces the opportunity for system crashes and enhances overall system speed. Before I talk about how 32-bit access affects your computing environment, however, you need to understand what it is.

If you tried to figure out what 32-bit access is by its name, you might suspect that it's some new technique for accessing the data on your drive 32 bits at a time. What 32-bit access actually provides is a little more complex.

Every time an application requests data from the hard drive, Windows intercepts the request to see if it can be fulfilled using data in protected memory. Usually, the request asks to open a file or to read specific byte ranges of data. Once Windows determines that it can't fulfill the request, it switches to real mode and passes the request to the DOS interrupt 21h handler. This handler looks at the request and starts to take care of it by issuing interrupt 13h requests. You can look at interrupt 21h as the manager and interrupt 13h as the worker. Interrupt 21h gets the whole problem in one big chunk. It breaks the problem up into small pieces interrupt 13h can handle. As a result, each interrupt 21h call can result in a lot of interrupt 13h calls.

Of course, because Windows is monitoring everything, the system doesn't just stay in real mode and take care of the entire disk request at one time. Windows intercepts each interrupt 13h call the DOS interrupt 21h handler makes to see if it can fulfill the request using data in protected memory. If not, Windows switches back to real mode and the BIOS handles the call. The BIOS performs the work required to fulfill the call and passes the information back to Windows, which passes it back to DOS, which passes it back to Windows, which finally passes it back to the application. This might seem like a lot of work just to read a few bytes of data from the disk, and it is.

Figure 9.3 shows the new 32-bit access method used by Windows 3.1x. Notice the BIOS is completely cut out of the picture. That's because FastDisk (a 32-bit protected-mode driver) emulates the BIOS using protected-mode code. This means not only that Windows eliminates two mode transitions for every interrupt 13h call, but also that it can effectively multitask during more of the disk access cycle. You lose only the DOS processing time instead of both DOS and BIOS processing time. This improvement accounts for part of the noticeable speed-up in Windows 3.1x. It also accounts for some of the improved stability that people experience.

Figure 9.3. Windows 3.11 provides a 32-bit access feature that reduces the opportunities for a system crash and enhances system throughput.

Windows 3.11 and Windows for Workgroups 3.11 add even more. In addition to 32-bit disk access, these versions add 32-bit file access. These versions of Windows use the DOS file access features to search for files and to perform other file-specific activities. (This differentiates a file access from a disk access, which deals with reading and writing sections of data.) This means even fewer transitions to DOS because the file system no longer keeps the BIOS in the picture. The result is an overall improvement in system speed and reliability.

The Windows NT Alternative to 32-Bit Access


Windows NT gets around the entire real-mode access problem by incorporating all operating system functions into a 32-bit architecture. Microsoft has named this technique the VFAT interface for Windows 95; I've borrowed the same term for the service that Windows NT provides because from the user's point of view, it's the same. The full name for this type of disk access is the Protected-Mode FAT File System. Figure 9.4 shows how this disk management system differs from the one used under Windows 3.x. Using protected-mode drivers means there's less chance that a random application will cause a system failure because Windows NT is never unprotected for a long enough time. (In fact, unlike Windows 95, Windows NT is never in a state where it's unprotected because each application runs in its own memory space and it doesn't allow you to use real-mode drivers.) The VFAT file system always runs in protected mode. Using protected mode means the operating system constantly monitors every event taking place on the machine. It has the final say before a particular event takes place. This new system runs totally in protected memory, reducing to nearly zero the chance of system crashes due to disk-related problems and greatly enhancing disk access speed.

Figure 9.4. Windows NT uses a totally different system from its predecessors to access this disk.

Figure 9.4 shows several discrete components in the Windows NT file system. Actually, Microsoft refers to these components as layers. The Windows NT file system has 32 possible layers, starting at the I/O subsystem. (The current configuration doesn't use all 32 layers.) Layer 0 is closest to the I/O subsystem, whereas layer 31 is closest to the hardware. The current version of Windows NT only requires a few (usually 12) of these layers to get the job done. The other layers are placeholders for future use. Each layer provides hooks for third-party software used to support custom file systems and devices. Adding a network driver to the file system layer enables you to access drives on other machines, for example. Unlike previous versions of Windows, a vendor can retrofit the Windows NT file system to provide additional capabilities with relative ease. I already covered these various tasks as part of the architecture discussion (you can also see them in Figure 9.1) so I won't go into details again here.

Gaining Access to VFAT from DOS


You can access the VFAT interface in a DOS application. Microsoft incorporated a new set of services into the interrupt 21h handler. Table 9.1 shows the various calls you can make to this new interface. Notice the AL part of the service call corresponds to the current disk service call numbers. The contents of the other registers correspond to the old DOS register setups as well. If you know how to use the current set of interrupt 21h disk routines, using the new ones means a simple change in the contents of the AX register (in most cases). Microsoft recommends you use the Get Volume Information (71A0h) to detect if the current system supports long file names. Set the carry flag before making the call. If the machine doesn't support long file names, the carry flag will be unchanged on return, and DOS will clear the AL register. Never use the long file name calls on a system that doesn't support them. Remember that all of these service numbers go into the AX register and that the values are in hexadecimal format.

Table 9.1. VFAT interface interrupt 21h functions.

AX Code Function Name
7139h Create Directory
713Ah Remove Directory
713Bh Set Current Directory
7141h Delete File
7143h Get/Set File Attributes
7147h Get Current Directory
714Eh Find First File
714Fh Find Next File
7156h Move or Rename File
716Ch Extended Open/Create File
71A0h Get Volume Information
71A1h Find Close

The HPFS File System


This section gives you a very quick overview of the HPFS file system. I'm not going to spend a lot of time with HPFS simply because it's less important in some respects than it used to be to many Windows NT users. The main reason that Microsoft originally included HPFS support with Windows NT was to make the move from OS/2 to Windows NT easier. As of this writing, Microsoft no longer plans to directly support HPFS on Windows NT 4.x and above, although there are ways to get around this problem. (See the tip near the beginning of this chapter to find out one way to do it.) The bottom line is that NTFS is so superior to HPFS that there are few reasons to use HPFS anymore.

You might want to consider a few things before discarding the HPFS file system totally—especially if you're a software developer. If you need to run both OS/2 and Windows NT on one machine and DOS isn't in your future, then HPFS makes a much better choice than the FAT file system for storing data. Not only does HPFS provide better security and improve system performance, but it also provides an advanced system of file attributes. HPFS can provide you with version information about a file, for example—something that VFAT still can't do. In addition, even though Windows NT's version of VFAT enables you to store long file names, you can't use VFAT with OS/2; OS/2 will see it as a regular FAT formatted drive. HPFS represents the only file system where both OS/2 and Windows NT can use long file names and other extended attributes on the same drive.

One of the ways that HPFS exceeds the capabilities of the FAT file system is that it provides a hot fixing capability. If you've ever run into a situation where an application wrote to a bad disk sector and you ended up with garbage in a file, then you've experienced one of the problems that a hot fix can cure. If an application experiences an error that doesn't allow it to continue performing file I/O, it's up to the operating system to take over. Unfortunately, the FAT file system doesn't provide the tools for the operating system to do this. HPFS, on the other hand, provides a special area on disk with known good sectors. When OS/2 (or Windows NT) finds a bad sector, it places the data that was supposed to go into the bad sector into a sector from the hot fix pool. Although this particular strategy does take care of problems that the operating system can monitor, it doesn't take care of those that the operating system can't control. A power or CPU failure will damage a disk that uses HPFS just as quickly as its FAT counterpart, for example. NTFS provides advanced capabilities that can also overcome some of these other obstacles to keeping your data intact.

Storage capacity is another reason that Microsoft originally designed the HPFS file system. It can store more information in smaller clusters (one data storage unit) than the FAT file system can. Table 9.2 provides a complete list of these statistical features for FAT, HPFS, and NTFS. (VFAT and FAT share the same size constraints.)

Table 9.2. File system statistics comparison.

Statistic FAT HPFS NTFS
Maximum Partition Size 216 232 264
Maximum File Size 216 224 264
Cluster Size 512 byte+ 512 byte 512 byte-4KB

Some of these statistics are a bit obscure, so I'm going to take a moment to fill you in on the more important ones. When you look at the maximum partition size entry, what you're really seeing is the number of entries the partition can contain. To convert this into a number that looks more familiar, multiply the number of entries by the cluster size of your hard drive. A cluster is one allocation unit for your hard drive—the amount of space that a single entry actually consumes. A FAT-formatted drive that uses a 512-byte cluster, for example, can hold 32MB of data (2[16] entries x 512 bytes). As you increase the size of the hard drive partition, DOS (or Windows) has to increase the size of the cluster. A 65MB hard disk uses a 1KB cluster, for example. DOS also has to allocate those clusters as a power of 2. Even though a 10KB cluster would allow you to use a 650MB partition, DOS has to use a 16KB cluster instead. This means that if your file is only 2 bytes in size, FAT still allocates 16KB of disk space to hold it. The computer industry has a name for this problem—internal fragmentation.

HPFS provides a bit more in the way of disk capacity. It provides 4,294,967,296 entries in a partition. Because OS/2 (or Windows) uses something called a signed number (one that allows both positive and negative numbers) for the HPFS file system, however, the actual number of entries is 2,147,483,648. This number might seem high enough to tackle any situation, but it isn't. A few hidden HPFS limits will eventually make it obsolete. HPFS uses a fixed cluster size of 512 bytes. That means the largest HPFS partition you can use is 1TB—a very large drive indeed but still limited. HPFS also limits you to a maximum file size of 4GB (224 entries / 2 (because of signed entries) x 512 byte cluster). The fixed cluster size used by HPFS has another limitation. Even though all American drives use a 512 byte cluster, some Asian drives only come with a 1,024 byte cluster. You can't use HPFS on those drives because of its fixed cluster size.

NTFS starts out with more entries than either of the previous file systems—1.844674407371 x 1019 to be exact (that's 16,777,216 Tera entries). Like the FAT file system, the size of a NTFS cluster can vary in size, but Microsoft limited the variation to a range of 512 bytes to 4KB. This cluster size is flexible enough to allow you to use non-standard drives, provide growing room for future needs, and still reduce the amount of internal fragmentation you'll see. You won't soon find the limit of a NTFS drive even if you use the smallest cluster size.

I could probably go on for a few more pages, but I think I've made my point. HPFS was an important step in file system evolution, but it's only a step. Developers or other people who need to run both OS/2 and Windows NT on one system will still want the benefits that this file system provides. If you're running Windows NT exclusively on your machine, however, NTFS is the way to go.

The NTFS File System


There's a lot of NTFS material to cover when it comes to Windows NT because Microsoft's always making this file system better. In fact, that's the first thing you need to know about NTFS; Microsoft designed it in such a way that they could easily extend it without causing any backward compatibility problems. The capability to extend NTFS isn't just in the hands of Microsoft either—every programmer can add new capabilities to what you see (I'll discuss this feature later in this section). This section of the chapter isn't meant as the end-all discussion of NTFS. What I give you is an overview of what makes NTFS special and why you should consider using it in place of the older file systems on your machine.

Layering and extending NTFS go hand-in-hand. I discussed this concept earlier as part of the layered approach that Microsoft uses in the design of the Windows NT file system. NTFS provides a lot more than just a layered and extensible file system, though. The idea of layering goes a lot further than that. You'll find that layering affects three areas of NTFS: multiplatform support, file attributes, and special features such as fault tolerance.

The multiplatform nature of Windows NT is one of the first ways that layering will help you directly as a user. I had previously mentioned that Windows NT is designed to support a variety of operating systems in addition to working with a variety of CPU types. One of the ways that it does this is by making the other operating system think that it's providing a specific service when it's really not. NTFS can mimic the capabilities of a POSIX file system, for example. One of these features is the capability to support case-sensitive names where FileName is different from FILENAME. Under FAT and HPFS, both names are the same because both file systems originally provided case-insensitive name support. You'll also find that NTFS supports hard links—the capability to give one file more than one name. Another POSIX-related feature is the capability to support multiple time stamps. It doesn't take too long to figure out that if you can tell NTFS to mimic these features, other file system features are just as easy to add. File system features are one of the things that keep operating systems from working together so this mimicry isn't just a minor addition to NTFS; it's something that will probably help you create multiplatform links somewhere along the way.

Another form of layering comes into play with file attributes. Both the FAT and HPFS file systems provide a very specific set of file and directory attributes. NTFS, on the other hand, uses a concept called streams to store file attributes. Each file attribute is a single stream and every file can have as many streams as needed to identify it. A programmer can attach a stream to an NTFS file using a simple mechanism in the file API. The way this mechanism looks to a user is FILENAME.EXT:StreamName. The colon (:) is a reserved character; you can't use it in a file name. Microsoft used this restriction as a method for adding named streams to a file. The name after the colon is the stream; it's used to find a specific attribute attached to the file. What does this mean to you as a user? It doesn't mean a lot right now. As more applications are designed to use NTFS, however, you'll find a lot of new attributes assigned to the files you use. A new attribute might be as simple as the name of the person who created the file or the version number of this particular file. Complex attributes might include things such as the resolution and number of colors for a PCX file.



Note: The multiple stream capability of NTFS does provide one unique feature that a lot of people will find handy. A Macintosh file contains two streams: one for data and another for resources. The data stream might include the creating application's name. The resource stream includes the file type and tells what icon to attach to the file. Until now, that data always got lost when a user transferred a file from a Macintosh to a PC. The multiple stream capability of NTFS makes it possible for PC and Macintosh users to exchange information now without any loss of resource information.

Fault tolerance has become more and more important as companies place more of their critical data on PCs. In the previous section, I discussed the hot fix capabilities that HPFS provides for taking care of certain types of disk problems. That system falls short in a lot of areas that make it unacceptable for business. NTFS gets around many of these problems by using an entirely different system. Those of you who work with database management systems will recognize this strategy instantly because NTFS uses the same time-tested strategy. Every time an application performs a disk operation, Windows NT stores the transaction in a log. The transactions keep piling up until the application closes the file or signals that it's finished in some other way. What happens if a system crash occurs before the file transactions are complete? Windows NT can use the log entries to either rebuild the file or reverse the file changes; it all depends on when the system error occurs. This system even works for bad sectors because Window NT uses the log to verify the contents of the file. The end result is the same as using the hot fix strategy that HPFS provides—at least for events that the operating system can monitor—but the log strategy also protects against things that the operating system can't foresee, such as a power outage.

Security is another area where the file system comes into play. Chapter 21 provides a lot more detail about this subject in the section "System Security and the Administrator." It's important to realize that the security I discuss in that chapter extends to the file system, though. Windows NT looks at every system resource, including disks, folders, and files, as objects. To gain access to an object, you must have the proper access token. Think of an access token as a key that consists of the password and other access features that Windows NT provides. In other words, to access any part of the NTFS file system, you have to have the right access. Unlike the FAT and HPFS file systems, you can't bypass this security by loading another operating system. Everything is under Windows NT control—which means that your data is a lot more secure.

The security area isn't the end of the special feature list. You can add Unicode (16-bit) characters to a file name on a NTFS partition. This extends the file names in the area of language. In addition, NTFS provides B-Tree indexing just like HPFS does. HPFS only indexes standard attributes, however. NTFS enables you to create indexes for all the attribute streams. This means that you could search a disk for the name of a particular document author or a version of a program used to create a data file. The possibilities are unlimited—something that you probably haven't heard from other file systems.

By now, it should be obvious why you would want to switch from VFAT or HPFS to NTFS. The thing to remember is that some of these features aren't in use today; you won't actually get to see them until application development catches up to the changes that NTFS provides. However, isn't it good to know that those capabilities are available and that you'll eventually be able to use them? I think that the future of computing is the NTFS file system—at least until someone thinks of a better idea.

Volume Management


Windows NT—both server and workstation versions—provides a lot more in the way of volume management capabilities than older versions of Windows do. I find that working with Windows NT is a lot easier than what I've used in the past. Anyone who has spent time wandering the menus of FDisk when creating a complex system setup knows exactly what I mean.



Note: This book is designed for the workstation version of Windows NT. I'm not going to cover some of the features provided by the server version of the product such as RAID. I think that these are important features, and I hope Microsoft eventually adds them to the workstation product as well. For now, though, I'll cover the features that the workstation version of the product does provide. I think you'll still find that the features are well ahead of what you saw in previous versions of Windows.

The first thing you should do before you use this section is find the Disk Administrator program. It's under the Administrative tools section of the Start menu. The first time you start this program, Windows NT will ask if it can put a signature byte on all your drives. Don't worry; this is a harmless procedure and won't affect the operation of your drives—even if you use them with DOS or OS/2. The signature byte simply provides a method for Disk Administrator to identify the disk. Once you do this, you'll see a display similar to Figure 9.5. Obviously, my disk layout is different from yours, so you won't see precisely the same things that I show throughout this section of the book. Just use the screen shots as a guideline for your own machine.

Figure 9.5. The main Disk Administrator screen shows an overview of the disks on your machine.

The initial view provided by Disk Administrator shows a graphic layout of the disks and partitions on your machine. Figure 9.5 shows three kinds of partitions: primary partition, extended partition, and free space. Other partition types include stripe set, stripe set with parity, mirror set, and volume set. You'll find that the various spaces representing a partition provide a drive letter, volume label, partition type, and the size of the partition. You'll also find the total size of a drive and its designation on the left side of the display.

You can use another way to view all of the partition information. Just click the Volumes View button on the toolbar and you'll see a display similar to Figure 9.6. Notice that this display contains most of the information that the previous display did. It also contains one additional piece of information that you'll find essential. Notice the fault tolerant column in this display. All the other extra columns that this view provides relate to this one additional column. I'll take another look at this issue later, so remember that all of my disks are currently not fault tolerant.

Figure 9.6. The Volumes View enables you to see the current volume status in tabular format.

You can also view the current statistics for a single partition. Just click the third button on the toolbar. It displays a dialog box similar to Figure 9.7 for the currently selected partition. If you want to see a different partition, you'll have to select it separately and then click the third button again. Disk Administrator doesn't provide any way to move from disk to disk in this view.

Figure 9.7. The Volume Properties dialog box enables you to see the current statistics for a partition.



Tip: You'll find the same tools I just described for the Volume Properties dialog box on the Tools menu. The Tools menu also contains an entry that enables you to change the drive letter of a partition.

Now that you have a basic idea of how to view the information that Disk Administrator can provide, take a look at some of the other tasks you can perform with it. Windows NT enables you to a lot of things that you couldn't under previous versions of Windows. The following sections talk about all the capabilities that the workstation version of Windows NT provides. You'll find that the server version provides all of these features plus some server-related features such as RAID.

Creating a Partition


The most basic operation you can perform with the Disk Administrator is creating and formatting a partition. Windows NT supports two kinds of basic partition: primary and extended. These are the same options that FDisk supports. The only difference is that you don't have to leave Disk Administrator and reboot the machine before you can access the new partition. The following procedure shows you how to create a primary partition. Creating an extended partition is the same. The only difference is that you use the Partition | Create Extended command instead of the Partition | Create command. I'm assuming that you have Disk Administrator open to start this procedure.

  1. Select a free space on one of your drives. The default Disk Administrator setup shows a free space as a black hatched area.

  2. Use the Partition | Create command to display the Create Primary Partition dialog box shown in Figure 9.8. Notice that the dialog box contains two statistics. The first tells you the size of the smallest partition you can create. The second tells you the maximum area available for a partition. You have to select a partition size between these two numbers.

    Figure 9.8. The Create Partition dialog box enables you to select a specific partition size.



    Note: If you choose to create a primary partition on a disk that already contains a primary partition, Disk Administrator will display a confirmation message. The intent of this message is to warn you that the partition might not be accessible from other operating systems such as DOS. If you want to create a FAT partition that's accessible from both DOS and Windows NT, then you need to create an extended partition.

  3. Select a partition size and click OK. You'll see a new, unformatted partition similar to what's shown in Figure 9.9. You need to format the partition before you can use it. The newest version of Windows NT has two formatting possibilities: FAT and NTFS. Windows NT Version 3.51 and older also support HPFS as a formatting option.

    Figure 9.9. You have to format a new partition before you can use it.

  4. Use the Partition | Commit Changes Now command to record the changes you just made to disk. You have to take this step before you can format the partition. Disk Administrator doesn't make any changes permanent until you save them—allowing you to change your mind. If Disk Administrator successfully saves the changes, you'll see a success dialog box. Click OK to clear it.

  5. Make sure you select the new, unformatted partition. You don't want to accidentally erase the data in an existing partition.

  6. Use the Tools | Format command to display the Format dialog box shown in Figure 9.10. This dialog box has three elements. The Label field contains the name of the drive as you'll see it from the DOS prompt and within Explorer. The Format Type defines the file system that Windows NT will use for the partition. The Quick Format checkbox enables you to bypass the extensive formatting that Windows NT usually performs on a partition. I usually keep this box unchecked on a drive because I want Windows NT to verify that the disk is good before I use it.

  7. Enter a label and select a format type. I usually use NTFS unless the partition will be used by DOS or OS/2. Click OK to complete the action. Depending on whether you select Quick Format, it might take Windows NT a while to complete the disk format. Disk Administrator will display a progress dialog box so that you know where it is in the formatting process. Once the formatting process is complete, you'll see a completion dialog box like Figure 9.11. Notice that this dialog box shows you the full and formatted capacity of the drive.

    Figure 9.10. The Format dialog box enables you to prepare your drive for use.

    Figure 9.11. Disk Administrator informs you when the disk formatting process is complete.

  8. Click OK to clear the completion message. You've just created a new disk partition.


Volume Sets


Sometimes, you might want to refer to one huge drive rather than a lot of small ones. Under DOS, this was suicide for drive space because of the large cluster sizes involved. Windows NT has no such problem; you can effectively use a 512 byte cluster for most drive configurations that I can think of today. Even if you do need to go to a 1KB cluster size for an Asian drive, you're still ahead of what DOS could do for you. Even a 4KB cluster size for a very large drive wouldn't be that significant. Creating volume sets enables you to create one huge drive out of a lot of small ones. It allows you to refer to that drive using one drive letter. The following procedure builds on your knowledge from the previous section to create a huge volume from two or more free spaces. As with the previous section, I assume that you have Disk Administrator open.

  1. Select a free space on one of your drives. The default Disk Administrator setup shows a free space as a black hatched area.

  2. Press the Ctrl key and select all the other free spaces that you want to combine into one huge volume. It's essential to press the Ctrl key; Windows NT doesn't allow you to Shift select a range of free areas.

  3. Use the Partition | Create Volume Set command to display the dialog box shown in Figure 9.12. As with the Create Partition dialog box shown in Figure 9.8, you'll use this dialog box to set the size of the new partition.

  4. Click OK to complete the partition assignment. You'll see a new unformatted volume set as shown in Figure 9.13. Notice that Disk Administrator treats this partition differently from the basic partition you created in the previous section.

    Figure 9.12. The Create Volume Set dialog box enables you to determine how much of the combined volumes to use in one partition.

    Figure 9.13. Creating a volume set enables you to use one drive letter to refer to more than one partition.

  5. Use the Partition | Commit Changes Now command to record the changes you just made to disk. You have to take this step before you can format the partition. Disk Administrator doesn't make any changes permanent until you save them—allowing you to change your mind. If Disk Administrator successfully saves the changes, you see a success dialog box. Click OK to clear it.



    Note: Creating a Volume Set might require that you shut down your computer to make the change permanent. Disk Administrator will tell you if this step is required. Continue with the procedure once you restart your machine.

  6. Make sure you select the new, unformatted partition. You don't want to accidentally erase the data in an existing partition.

  7. Format the new partition as you did in the previous section. You'll see a new drive added to Explorer. It's important to remember that this new drive spans more than one drive. The Volumes View shown in Figure 9.14 reflects this fact. Notice that it also tells you the condition of the spanned volume (volume set in Microsoft terms).

Figure 9.14. The Volumes View is where you see the current status of a volume set.

Volume Extensions


Have you ever wondered what to do when your current hard disk gets too small, but you really don't want to take the time to move everything to a new one? In the past, that's the only choice you had—buying a new drive, installing it, and then moving everything from your old drive to the new one. Adding a new drive meant that you would have a bunch of new drive letters and had to reset all your INI files to match the new system configuration. I usually didn't look forward to adding new drive capacity, and I don't know of a single person who does.

Windows NT has a solution for this problem. In the previous section, I showed you how to create a volume set. Essentially, you're spanning several hard drives—making several small hard drives into one huge one. You can do the same thing with an existing drive. Install a new drive and use the two drives together as one. All you need to do is follow the same procedure that you used in the previous section to get the same results. You'll need to make a few minor changes, however, and describing them is the purpose of this section.



You can't use this procedure to update your main Windows NT volume. Disk Administrator will stop you from doing so. The reason is fairly complex, but it comes down to Windows NT being able to find the files it needs in order to perform an update of the drive system.

Warning: Always back up the data on the existing drive before you perform this procedure. Although that's good advice any time you want to make a system change, it's especially important now. Even though Windows NT never lost any data on the drives I tested when using this procedure, you don't want to make your data a test case.

The first thing you need to do is add the existing drive to the list of drives you're selecting. When you do this, Disk Administrator highlights the Partition | Extend Volume Set command instead of the Partition | Create Volume Set command that you used previously. Use the Extend Volume Set command in place of the previous one to create the huge partition.

Another change is the way that the new hard drive space is incorporated into the system. Windows NT insists that you restart the system. During the startup process, you'll see a few additional entries as Windows NT incorporates the additional space. A call to CHKDSK is one of the last steps in the update process.

In addition to all these other differences, you don't need to format the new addition to your drive. Windows NT takes care of this during the update process when you restart your machine. Even though the update process seems to take forever, factor in the time it would have taken to format the drive. I think you'll find that either volume set process takes about the same amount of time.

Stripe Sets


Creating a stripe set is similar to creating a volume set. You can follow the procedure in that section and not run into any problems from a user's perspective. Some implementation differences make a stripe set totally different from a volume set from the Windows NT perspective, however.

You can create a volume set from free space on any drive. If you happened to have two free spaces on the same drive, you could combine them using the volume set technique. A stripe set must appear on different drives. You can combine up to 32 drives, but every free space used to create the stripe set must appear on a different drive.

Disk Administrator will also make every partition the same size. This means that your total stripe set size is limited to the size of the smallest disk partition multiplied by the number of disks. If you have a 100MB partition on one disk and a 500MB partition on another disk, for example, the maximum size of your stripe set is 200MB, not the 600MB you'd get from a volume set. Figure 9.15 shows the differences that these limitations make in the Disk Administrator display for a stripe set. Compare it to the volume set that I showed you in Figure 9.13.

Figure 9.15. A stripe set has several limitations when compared to a volume set.

If a stripe set has so many limitations, why use it at all? Using a stripe set does have a big advantage as well. Consider for a second how a volume set works. It lays the data on the drives in a linear fashion. This means it uses all the space on the first partition, then the second partition, and so on until all the partitions are used. Linear reading and writing means that only one partition is used at a time. A stripe set places the data on the disks in stripes. This means that each drive is used equally. If you think about it for a second, you'll see why this is such a big deal. Using all the drives simultaneously means better throughput—you can actually see a performance gain using this technique.

The one thing you shouldn't do is confuse the striped set provided by the workstation version of Windows NT with the RAID support provided by the server version. Unlike RAID, a striped set doesn't provide any form of protection for your system from a disk failure; there isn't any fault tolerance present when using a stripe set. In fact, you'll actually find that stripe sets are less reliable than a standard volume because a failure in either drive results in data loss. If you look at the Volumes View, you'll see a picture similar to Figure 9.14, which is why I made a special mention of the fault tolerance column at the beginning of this section. Windows NT workstation will support fault tolerance if you're downgrading from the server version of the product and installed fault tolerance previously. It won't support fault tolerance right out of the box.

Data Compression


One of the best user features that using the NTFS file system provides is data compression. Figure 9.16 shows the context menu for a file stored on a NTFS file system drive. Notice the Compress and Uncompress options on this menu. If you right-click a file stored on a FAT or HPFS file system drive, you won't see these entries. Unlike its predecessors, the NTFS file system doesn't force you to compress files using a third-party utility—at least not if you just want to save space on your disk. All you need to do is select the Compress option on the context menu.

Figure 9.16. NTFS provides a Compress feature that its predecessors don't.

How well does this feature work? Using this feature is quick and painless. I decided to compress a somewhat large file to see how well it works. I didn't even notice any system activity and thought that the command had failed. Clicking the file and seeing that Explorer reported it was still the same size only seemed to confirm my suspicions. Opening the Properties dialog box showed the real story (see Figure 9.17), however. The file was compressed to nearly 58 percent of its former size, a substantial savings. The amount of space available on the drive also reflected the change in compression status.

Figure 9.17. The File Properties dialog box shows the result of compressing a file on a NTFS volume.

Don't get the idea that this on-the-fly file compression is free. I did notice a slight decrease in system performance when accessing the compressed file, so you won't want to use this feature with files that you use a lot. For graphics or other large files that you use infrequently, though, the file compression provided by NTFS makes perfect sense.

New Extensions: LNK Files


Pointers is a term familiar to programmers when used as a computer term or to all of us when talking about a directional finder. Think of LNK files in Windows NT as pointers to something. They enable you to create an image of any Windows 95 or Windows NT object somewhere else. In most cases, the object is a file or a folder.

What good are LNK files? Assume you're a manager and you need to get a bunch of files for the group that will eventually put a project together. A graphics illustrator has worked creating drawings for the last few weeks. A second group worked up all the figures and statistics with Lotus 1-2-3. Still another group worked on some text and charts to go with the other elements of the project. You're ready to get everything together for a full-fledged presentation.

You could copy all the files to one directory and print them out. After a lot of red lining during your meeting, each group could make the required changes. What an inefficient way to spend your week. This is the way a lot of places work, but I can't think of anything less productive.

Of course, some groups have become more modern. They place all the files in a directory on the network so the group can work on them without making red lines. This is a bit better, but it's still not optimum because you have two copies of the files lying around now. This allows too many chances to make a mistake. Besides, what happens if Sheryl finds another change later? Does she try to find the correct file and make the change (or worse still, try to find the correct person to make the change for her)? Using double files is okay, but it's still not the right way to go.

Windows NT offers a new alternative. The manager can now create a project folder containing links (or pointers) to all the project files. The folder is easy to distribute to everyone who is working on the project, even if they aren't in the same building. The links (.LNK files) make it easy for the person using the folder to access a single copy of the real file. No duplicates are needed. There's no chance for mislaid files, everyone can work on all the files as needed, and no one but the manager needs to know the physical location of the files. This is what a LNK file can do for you. (The only down side to using LNK files and therefore a common data file is that your application must be set up for file sharing.)

Of course, using LNK files can help a single user manage his or her work just as easily. In fact, I discuss some of these methods in the section "Working with Desktop Objects" in Chapter 2, "Exploring the Interface." I have found I can manage all my work as projects and not really worry about applications or the actual location of the data. LNK files are a small idea with big implications. Take a look at some of the details.

Your Start Menu folder contains a ton of LNK files. If you think that any of your applications actually appear in the Start menu, you're wrong. Only the pointers to those files appear here. If you erase a Start Menu entry, all you erase is a LNK file, not the application itself.

Right-click the Start Menu icon on the Taskbar and select the Explore option. What you should see now is a dual-pane Explorer view of your Start Menu entries. You can easily recognize the LNK files because they look like shortcuts (the icons with the arrow in the lower-left corner). Right-click any of the LNK files and you'll see a display similar to Figure 9.18. (I chose the Windows NT Explorer LNK file, but any choice is acceptable for this discussion.)

Figure 9.18. A LNK file's Properties dialog box provides a General page similar to that provided by other file types.

As with the General page of any file Properties dialog box, you can set the file attributes: hidden, archive, and read-only. This page also tells you the short and long file name and other statistics, such as when someone last modified the file. This is all interesting information, but you'll probably bypass this page in most cases to get to the Shortcut page. Figure 9.19 shows what this page looks like.

Figure 9.19. The Shortcut page contains all the LNK file setup information.



Looking Ahead: I'll discuss the security page of this dialog box in the section "Using the Security Page of the File or Folder Properties Dialog Box" in Chapter 23, "Security Issues." As with every other object provided by Windows NT, shortcuts provide a wealth of security options.

The following list outlines the four major fields on the Shortcut page along with the function of each entry. Of course, the two you'll use most often are the Target and Run fields. I personally never use the Start In field, but you'll probably need it some places.

That's all there is to LNK files. Chapter 5, "Startup Shortcuts," gives you some usage tips for LNK (or shortcut) files. You should read about the various methods you can use to create shortcuts to your data files and applications. Chapter 2 also discussed this topic in the section "Working with Desktop Objects" from a Desktop point of view. The Desktop is where you can really benefit from using these productivity enhancers.

VxDs and DLLs


Modular programming is the way to go these days. Programmers will tell you the reason for modular programming is that it's easier to maintain and understand. Those are perfectly good reasons, but they don't really tell you much as a user. The user's view of modular programming has to do with memory. It takes a lot of code to tell your machine how to get anything done when using a GUI, such as Windows NT. More code always translates into more memory. If you replicated the common code Windows needs for tasks, such as displaying a dialog box, for every application you ran, the memory shortage you would experience would dwarf the current problems.

Windows 3.x started the DLL (dynamic link library) and VxD (virtual anything device) craze for a good reason. Creating a Windows program is a complex undertaking, and programmers needed tools to get the job done quickly. A modular approach also ensures that things such as dialog boxes look the same no matter which application you use. The important reason for the current discussion is memory, though. People were already starting to complain about the huge memory footprint of Windows. Even when applications could share some code or data, it still took a lot of memory to get anything done. A GUI always requires more memory than a character-based operating system. If Microsoft had taken a DOS view of programming when designing Windows, we would all be using OS/2 today.

A program calls a DLL or VxD to perform specific tasks. Essentially, both files contain executable code—similar to a mini application. When Windows sees the request, it loads the program (DLL or VxD) into memory. Of course, this sounds similar to what DOS does with external files called overlays. In theory, DLLs and VxDs do act somewhat as overlays from a code use point of view, but that's where the similarities end.

Like overlays, both DLLs and VxDs contain entry points. Unlike overlays, any number of applications can simultaneously access the program file and use whatever parts are needed. You might have noticed that the File | Open command in most applications produces the same dialog box, for example. That dialog box is actually part of the COMMDLG.DLL file located in your SYSTEM directory. An application makes a call to the COMMDLG.DLL to display a File Open dialog box. Windows loads the DLL, looks for a specific function number, and then lets the DLL do its work.

Take a look at that COMMDLG.DLL file. Open Explorer and then the Windows SYSTEM32 folder. Right-click the COMMDLG.DLL file to display the context menu and select Quick View. Page down until you see the Exported Functions entry. It should look similar to Figure 9.20.

Figure 9.20. The Quick View display of COMMDLG.DLL can tell you a lot about the way Windows works.

Looking at this table, you'll notice two columns. I won't take the programmer's view of this information (that could fill a book of its own), but I can present a quick overview. The first column tells you the function number. The second column (the one that you're interested in) tells you the function name. Notice the kinds of things that a programmer can do with the COMMDLG.DLL. Especially important are function 1, which enables you to open a file; function 2, which allows you to save a file; and function 20, which displays the Print dialog box.

You can check out some of the other DLLs in the SYSTEM directory using this same method. Learning what the DLLs do for you can help when something doesn't work the way it should. What would you do if the File Open dialog box suddenly stopped working, for example? It might seem a very unlikely prospect, but data corruption can affect any file on your system. (If you were a Windows 3.x user, you might have found out about your system files the hard way when your system would stop working unexpectedly; DLL and other system file corruption was a fairly common problem for some people.) Knowing the File Open dialog box appears in the COMMDLG.DLL file could help you fix the system with just a few minutes' worth of work. All you would need to do is restore a good copy of this file from your backup. (I'll cover backups in Chapter 26, "Windows NT Maintenance Programs.")

What DLLs do for software, VxDs do for hardware. When part of your system needs to access a piece of hardware, it usually calls a VxD. Of course, drivers can also work with software components but from a different perspective than DLLs. Drivers always provide some type of interface to a system component. Some types of memory allocation are performed with a VxD, for example. This isn't a function most users would worry about, but it's very important to the proper functioning of your system. One of the most used VxDs on your drive is the VMM32.VXD. It combines the functionality of a lot of the older files you found under Windows 3.x into one file. (Most of these entries appeared in the 386ENH section of SYSTEM.INI.)



Tip: If you right-click a VxD file, you notice that it offers no Quick View option. To view the file, make a copy and give it a DLL extension. You can now use Quick View to see the header of this file. This same technique works with other executable file types as well. Unfortunately, about the only things the file header will tell you is the amount of memory that the VxD requires to load and some programmer-specific information, such as the size of the stack that the VxD creates. In most cases, it isn't worth your while to look at the file heading unless you're low on memory and you're looking for a peripheral to unload from your system. Unloading a peripheral device can free memory that you can use for applications. (Make sure you back up any drivers that you unload using the procedures at the end of this chapter.)


Viewing File Contents


I've already taken a long look at the process of viewing files in quite a few of the chapters in this book, so I won't bore you with a lot of details here. It's important to realize that Windows NT does come with some file viewing support built in. Most of the major applications you'll use are already entered in the registry. Other levels of file support come from registry entries made by your applications during installation. Even if your applications aren't successful during installation, you can always import the REG files they create to add support to Windows NT. Chapter 7, "Understanding the Windows NT Registry," discussed all of these types of file viewing support.

You can also add support to the registry for your own file extensions. I outlined one way to add it for existing files in Chapter 7. Chapter 2 shows you still other ways to add support for viewing files. The method you use to add file support isn't important. The important thing to consider here is how efficient the new support makes you. Customizing Windows NT to the way you work is the best way to use all the added speed that this product can provide. Using your old work methods means you'll actually ignore those new features—a major problem with some people who have tried Windows NT and have been disappointed in its performance.



Tip: OLE is a real memory hog when it comes to moving data from one major application to another. You can usually accomplish the same thing by using a small application such as Notepad, Wordpad, or Microsoft Paint as the server in place of the major application you usually use. Adding multiple application support could make OLE practical on machines that usually don't have enough memory to support it. (I cover both DDE and OLE in detail in Chapter 12, "DDE and OLE.")

Here's a practical example of another type of file support you can add to Windows NT. I found the level of Explorer support for DOC files didn't meet my needs, so I changed it. That's one of the first rules you'll need to learn about Windows NT. Nothing's cast in concrete as long as you have some idea of what to look for in Explorer or the registry. In this case, I simply modified an Explorer entry to suit my needs.

Figure 9.21 shows the context menu I designed for DOC files. Of course, you could just as easily do the same thing for PCX or any other file extension, for that matter. Windows NT doesn't care how you customize your system; all it cares about is interacting with you and your applications when you get through.

Figure 9.21. Data viewing is fully configurable under Windows NT if you know how to use the registry.

Notice I can open DOC files with Word for Windows or Wordpad. I can also use the quick viewer to display the files when necessary. Another entry enables me to use Word for Windows to print the file without opening it first.

Now that you've seen the results, look at the implementation. Figure 9.22 shows the Explorer entries I made to create this context menu. You can use it as a basis for making your own changes. All I did was open the Options dialog box using the View | Options command in Explorer. Then, I selected the File Types page and Microsoft Word 6.0 Document. Clicking Edit displays the dialog box shown in Figure 9.22.

Figure 9.22. Creating your own context menus for viewing files under Windows NT is as simple as adding a few registry entries.



Tip: It almost always pays to associate more than one application with the files you use most often because memory limitations will sometimes prevent you from opening the full-fledged application you usually use to view or print the file. Adding a second application with a smaller footprint ensures that you'll always have access to your data files.

Adding the Quick View option is simple. Just mark the Enable Quick View checkbox. Windows NT has a problem here. It will enable you to mark this checkbox even if Quick View doesn't support your application. You should check the Windows NT documentation and any Windows NT application documentation for application support before you check this box.

The Wordpad entry is almost as simple to make. Click New to add a new entry to the list of actions. Type the information shown in Figure 9.23. That's all there is to it. Click OK three times to save your new entries, and you'll have a custom context menu for DOC files.

Figure 9.23. Adding new options to the context menu for a file extension is as simple as adding a new option to this dialog box.

Viewing files under Windows NT doesn't have to be the painful experience it was under Windows 3.x. I won't say that customizing your system is easy; it certainly isn't as easy as it could be. At least Windows NT provides the means to do it, though.

Formatting Disks


Formatting floppy disks is one of those tasks that everyone must perform from time to time, such as taking out the garbage or doing the laundry—something you'd rather not do but end up doing anyway. I found the old File Manager interface under Windows 3.x difficult to use for any length of time because the interface was so convoluted—it was more work to use the File Manager than the FORMAT command at the DOS prompt. Besides, formatting floppy disks in Windows 3.x was slow, and I could never get it to work right in the background. It was just faster and easier to get the job done from the DOS prompt.

I took another look at formatting floppy disks when I got Windows NT installed. Windows NT does improve on the interface problem. All you need to do is right-click the drive you want to format from within Explorer, as shown in Figure 9.24.

Select the Format option and you'll see the dialog box shown in Figure 9.25. This dialog box should look somewhat familiar. It's actually an improved version of the same dialog box that you used under Windows 3.x. I say improved because every field is self-explanatory now. There's no guessing about what this checkbox or that list box might do.

Figure 9.24. Windows NT always displays a Format option for any drive that supports formatting.

Figure 9.25. The Windows NT Format dialog box is an enhanced version of the File Manager dialog box used with Windows 3.x.



Tip: Always use the Quick Erase option to format floppy disks that you know are good. This option formats the floppy disk in a little over one-tenth the time a full format takes.

All you need to do now is select the options you want and click OK. Windows NT did offer a few nice surprises in addition to the interface. For one thing, it works very well in the background. I didn't experience a single problem with working on something else while the floppy disk took its time formatting. Of course, Microsoft didn't fix everything; formatting under Windows NT is just as slow as it was under 3.x.



Tip: You can double or even triple your formatting capacity by selecting network floppy disks to format under Windows NT. A peer-to-peer connection enables you to use the floppy disk on another machine if you have access. Using two machines in close proximity in one office doubles the number of disks that you can format at once.


On Your Own


Spend some time looking at the file system related files in the Windows SYSTEM folder. Look especially at the exported functions for DLLs such as COMMDLG.DLL. What do these entries tell you about the DLL and its purpose?

If you own a CD-ROM drive, spend some time optimizing the VCache now that you know a little more about how it works. What size CD-ROM cache seems to use memory most efficiently? How much of a speed difference do you notice between a large and small cache when using applications directly from the CD-ROM drive?

Determine what kind of an effect disabling lazy writes has on your system from a performance perspective. Use the following procedure to disable it. (If the performance penalty is too great, you can always use this same procedure to enable lazy writes again later.)

  1. Right-click the My Computer icon and select Properties.

  2. Click the Performance page and then the File System button.

  3. Select the Troubleshooting page. Click the Disable Write Behind Caching For All Drives option.

  4. Click OK twice to save your changes. Windows will tell you to reboot your machine in most cases to enable the change to take effect.

Previous Page Page Top TOC Next Page